前言

昨天是我們與 Fluent API 的初次見面，我們使用他來建立 Table 之間的關聯。

而今天我們將繼續使用 Fluent API，並使用它來建立 Table Column 的屬性。

欄位屬性設定

初步規劃

今天要對 EventsInfo 進行設定，我們先來看看目前的欄位屬性吧。

• 這張表的所有欄位我都想設定為 Not Null
• PersonalSite 為儲存網址的欄位，在 Stack Overflow 一文表示，url 最長為 2083 字元，那麼我這裡就預計設定為 nvarchar(2090)。
• Location 將存放場地、地點的資訊，預計設定為 nvarchar(100)
• FullIntro 將存放活動的完整介紹，預計設定為 nvarchar(1000)

那麼接下來就開始撰寫 Code 吧。

使用 Fluent API 設定欄位屬性

還記得 Fluent API 的 Code 該寫在 DbContext 中的 OnModelCreating Function 對吧，
那麼以下就直接列出這三個欄位的 Code：

這次在撰寫 Code 時，應該比較順暢了吧！依照前一篇的經驗，我們一樣用這樣的邏輯下去寫：

1. 目標是 EventsInfo 這一個 Entity
2. 針對此 Entity 的 Property 做調整
3. 需要有最大長度的限制
4. 必填為是

Migration 的內容：

確實有產生這三個欄位的更新內容，那麼就 update 到 DB 吧：

可以看到長度被設定好了，而且也不允許儲存 Null 了！

Views 是否還會依照欄位來自動套用驗證？

相信你會好奇，如果以 Fluent API 的方式來設定欄位屬性，那麼在 Submit Form 前，前端會有 Validate 嗎？
沒關係，我們就直接試試看！

這是使用 Scaffolding 的 EventsInfo 的 Create.cshtml，可以看到在剛剛我們設定的那三個欄位，是有套用 validate 的 Tag Helper（就是 asp-validation-for 這一個東西，後續文章會來講解這個東西），乍看之下好像也有前端驗證的方法對吧，我們實際來看頁面：

這是我點擊 Create Btn 後的結果，可以看到只有第1, 2 欄位有前端驗證，因為他們是 int 的欄位格式，我們剛剛設定的那三個欄位並沒有驗證。

這邊就直接解答，其實 asp-validation-for 這一個 Tag Helper 是跟著 Model 中的 Attribute，也就是說我們欄位的一些驗證或是自訂錯誤訊息，還是得在 Model 中設定，那麼經過這一個小實驗也可以確實了解，Fluent API 只在影響 Entity(Table)。

本日結語

藉由今天的內容，我認為如果今天要將 Model 的自訂屬性與 DB Table 做獨立設定的話，就可以使用到 Fluent API，因為 Fluent API 的影響範圍以目前的結果來看，只有影響到 Entity，這部分就留給讀者思考思考。

那麼這邊我會說一下，其他還沒設定欄位屬性的 Model，我會在自行做設定，因為步驟與先前的文章內容都大同小異，我就不會再寫一篇來說明我寫了哪些 Code，異動的紀錄可以瀏覽專案 GitHub，那麼我們就明天見啦。

Reference

Fluent API in Entity Framework Core

What is the best column type for URL?